1. Field of the Invention
Embodiments of the present invention generally relate to methods of controlling the clock of a network element deployed within a communications network and, more specifically, to enhanced clock control in packet networks.
2. Description of the Related Art
In many telecommunications applications, each element in the network has its own clock (referred to herein as a “client clock”) running independently of the other clocks in the network. Quartz oscillators typically serve as client clocks in network elements, providing frequency to support local timescale generation. While quartz oscillators offer good frequency stability over short term measurement intervals, their intermediate and long term frequency stability does not meet the telecommunications standards. Therefore, client clocks must be checked and corrected against external traceable sources. Furthermore, given the immense number of elements in the network, the clock of each element is required to not only provide good frequency stability over all measurement intervals, but also be reproducible throughout the entire network with the lowest cost per element.
There are several means of providing timing information to client clocks at the client network elements. In legacy telecommunications networks, network elements utilized time-division multiplexing (TDM) links, such as T1 and SONET, which are inherently capable of carrying reliable frequency information from a server to a client at the physical layer. However, next generation networks may be based on a packet-switched infrastructure (such networks are referred herein as “packet networks”) and there may be situations where the physical medium interconnecting network elements is no longer capable of transporting frequency information at the physical layer. Therefore, packet-based methods for transporting timing information are required. FIG. 1 illustrates a variety of timing sources that may be available to a network element 100. Timing sources include a Network Time Protocol (NTP) server 110, a Precision Timing Protocol (PTP) server 120, direct link sources 130, a multicast NTP server 140, a multicast PTP server 150, and a Real-Time Protocol (RTP) server 160. The NTP server 110 and the PTP server 120 enable packet-based methods for transporting timing information through an IP-WAN 115 and LAN 125, respectively. Unless specifically stated otherwise, the terms “NTP server” and “PTP server” as used herein mean that the servers operate in a unicast mode, where there is a secure one to one association between a server and a client ensuring a level of traceability. The direct link sources 130 are sources such as Global Positioning Satellite (GPS), Building Integrated Timing Supply (BITS), SONET, SDH, and PDH, which provide timing information to a network element through a direct link 135. The multicast NTP server 140 and multicast PTP server 150 are multicast servers, capable of providing packet-based timing information with an N to M association between a server and a client, where N and M may be any integer greater or equal to one and N<<M.
Even though a variety of timing sources may be available to the network element 100, not all timing sources are available in all cases. Also, their frequency stability is not always satisfactory for the telecommunications standard. The Multiple inputs Frequency Locked Loop (MiFLL) disclosed in U.S. Pat. No. 5,751,777 and U.S. Pat. No. 5,943,381, incorporated by reference above, achieves client clocks with good stability for any specified time measurement interval by optimally combining primary and secondary tier inputs. “Primary tier inputs” refer to timing information that comes over a verifiable (traceable) path from a known reliable timing source, such as the NTP server 110, the PTP server 120, or direct link sources 130. “Secondary tier inputs” originate from a better or equal stratum source than the local oscillator, but are not explicitly verifiable. The multicast NTP server 140 and multicast PTP server 150 could be used as secondary tier inputs, which would allow extracting time and frequency information with lower cost, lower power local oscillators without adding the burden of additional client transactions to the primary tier sources.
However, extracting time and frequency information from the multicast NTP and PTP flows creates several problems. First, it is not always known if these flows are sourced from a reliable server clock. Second, in practice, each packet in a flow experiences different delay with a significant random component, a phenomenon referred to as “packet delay variation” (PDV). As a result, inaccurate data may be sent to the MiFLL, compromising the performance of a client clock.
As the foregoing illustrates, what is needed in the art is a technique and apparatus for autonomously validating the time and frequency data obtained from multiple sources and generating a suitable estimates of the frequency differences between the client clock and the sources by mitigating the effects of PDV, so that only reliable data is sent to the MiFLL.